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A developer meets the process-tool 


"You will notice that there isn't a single 'best' way to do things; 

you have to think for yourself and figure out - based on your 
situation - your next step toward better software development." 

- Mary Poppendieck (http://www.poppendieck.com} 


"Kanban is based on a very simple idea. Work In Progress should be 
limited and something new should be started only when an existing 

piece of work is delivered " 


- David J Andersson(http://www.djaa.com) 


No silverbullets 


Process = how you work 

Tool = anything used as a means of accomplishing a task or purpose 

Scrum and Kanban are process tools in that they help you work more 
effectively by, to a certain extent, telling you what to do 



Manifesto for Agile Software Development 


• Individuals and interactions over processes and tools 

• Working software over comprehensive documentation 

• Customer collaboration over contract negotiation 

• Responding to change over following a plan 

That is, while there is value in the items on the right, we 
value the items on the left more. 


Source : http://agilemanifesto.org/ 
http://agilemanifesto.org/iso/en/principles.html 


Comparing 'process tools', Prescriptive to Adaptive 1(2) 
... “The value of a tool is that it limits your options” 


More prescriptive More adaptive 
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source : ‘Kanban and Scrum - Making the Most of Both’ by Kniberg & Skarin (pdf online) 





















Comparing 'process tools', Prescriptive to Adaptive 2(2) 
.... “The value of a tool is that it limits your options” 


• RUP, Rational Unified Process. A process that IBM owns 

- 120+ rules 

- you get to much, the idea is that you remove stuff you don’t need 

• XP, Extreme Programming 

- 13 rules ( depending on how you count) 

• Scrum 

- 9 rules 

- you get to little, the idea is that you add stuff that is missing 

• Kanban 

- 3 rules (Visualize Your Workflow, Limit your WIP (work in progress) and ? ) 

- leaves almost everything open 

source : ‘Kanban and Scrum - Making the Most of Both’ by Kniberg & Skarin (pdf online) 


Disclaimer... tool vs 'the team'... 


“Using the right tools will help you succeed, but will not 
guarantee success. It's easy to confuse project success/failure 
with tool success/failure.” 

A project may succeed because of a great tool. 
A project may succeed despite a lousy tool. 

A project may fail because of a lousy tool. 

A project may fail despite a great tool. 



A simple kanban-board 1(3) 


A simple kanban-board ( default in 'kanbanflow.com') 


To-Do (backlog) 

Do Today 

In-Progress 

Done 








This is the default board in https://kanbanflow.com 
- in scrum 'burndown-charts' are prescribed .... 









A simpler kanban-board 2(3) 


A simpler kanban-board 


Do Today 

In-Progress 

Done 

A 



B 



C 




Removed the 'To-Do' (Backlog)-lane 








A complex kanban-board 3(3) 



In-progress 


Do-Today (backlog) 

regression-testing 

functional-testing 

system-testing 

load-testing 

done 








This is a 'template' from https://kanbanize.com/ 











Online tools ... 


Not selling any online tools .... 
.... I have tried these two 

https://kanbanflow.com 
And https://asana.com/ 


Want to find more tools ? 

Google 'online tool for project management 


Is there Time to dive into Scrum ? 


Sprint Backlog 


Daily Scrum 
Meeting 


Backlog tasks 
expanded 
by team 




v Product Backlog 

As prioritized by Product Owner 


Potentially Shippable 
Product Increment 


Sourca Maclad from So.tw*r» 
Or'Vbfment wtt> Scrum tnr K»n 
Schwibef and Mika Bead* 


Source for image : http://www.scrumexpert.com/ 






























Scrum, prescribes 3 roles 


(sets product vision & priorities) 

Team (implements the product/service) 

Scrum Master (removes impediments and 
provides process leadership) 


In Scrum -> “you are free to add the roles you need” 



The Scrum Board 


• A Scrum board is owned by exactly one Scrum Team 

• A Scrum board is reset between each iteration, all 
items are removed 

• A Scrum board is visible to whoever is interested, but 

only the team may edit it 


Compared to Kanban, the Kanban-board is normally a 
persistent thing - you don’t need to reset it and start over 



Iteration (aka. Sprint) 

prescribes timeboxed iterations (1 to 4 weeks) 

3 stages : Beginning , During, End of 


Beginning of the iteration 

an iteration-plan is created - the Team pulls* out a specific number of 
items from the product backlog, based on the product owners priorities 
and how much the Team thinks they can complete in 1 iteration 


*pull&push 

the Team pulls item during the sprint, nothing is pushed into the sprint 







Iteration (aka. Sprint) 


3 stages : Beginning , During, End of 


During the iteration 

- The Team focuses on completing the items they 
are committed to 

- 'Daily standup' - daily meetings are prescribed (at 
most 15 min.) they are people oriented or board- 
oriented 



During the iteration 

Scrum resists change within an iteration 


so if ‘someone’ turns up and 
wants to add E to the board - 
then the scrum-team should 
reply ‘we are committed to 
A+B+C+D in this sprint’ 


Do Today 


In-Progress 


Done 




D 


B 








The burndown-chart 


The burndown-chart is 
prescribed in Scrum 

Shows on a daily basis how 
much work remains in the 
current iteration 

Velocity is a measure of 
capacity (how much can we 
deliver per sprint) 








Iteration (aka. Sprint) 


3 stages : Beginning , During, End of 


End of the iteration 

- The Team demonstrates working code to the 
relevant stakeholders , ideally this codes should be 
potentially shippable 

- Then the Team does a Retrospective* to discuss 
and improve their process 


The Retorspective 

4 questions , in this order 


1. What went well 

- starts the Retrospective on a 
positive note 


2. What didn’t go so well 

The purpose of the 
Retrospective is to improve, 
focus on facts 


3. What have I learned 4. What still puzzles me 


Concept 

'Definition of done' 


The team agrees on what this definition means 

an example from a programmer 

1) ‘clean code’*, committed to trunk** 

2) integration- and regression-tested 


* 'clean code', http://tinyurl.com/zdfswy8 

**trunk, see https://en.wikipedia.org/wiki/Trunk_(software) 


Scrum, short-summary 

Feedback-loop (1.2.3) 


Team #1 (single cadence) 

£ 'We do Scrum iterations' 
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Appendix A 

Manifesto for Agile Software Development 


"We are uncovering better ways of developing software by doing it and helping others do 
it. Through this work we have come to value: 

• Individuals and interactions over processes and tools 

• Working software over comprehensive documentation 

• Customer collaboration over contract negotiation 

• Responding to change over following a plan 

That is, while there is value in the items on the right, we value the items on the left more. 
Source : http://agilemanifesto.org/ , http://agilemanifesto.org/iso/en/principles.html 


Appendix B 

Retrospective 

“Retrospectives are popular in the team-working world of the Lean 
& Agile community but the technique was inspired by the wonderful 
work of Virginia Satir, the 'mother of family therapy'. 

She developed a technique called the Daily Temperature Reading, 
aimed at keeping relationships healthy and happy. 

Her questions were different, but the core of the method is first 
reflecting on what has happened in the past (both positive and 
negative) and then deciding on what to do in the future to improve.” 

source : http://tinyurl.com/hgc8ocu 

More on Virginia Satir: https://en.wikipedia.org/wiki/Virginia_Satir 



Appendix C 

Kritik mot den Agila Modellen 


(Computer Sweden 2009-11-05), Dan North 

http://computersweden.idg.Se/2.2683/l.267157/nu-vaxer-kritiken-mot-scrum 


“Scrumiden har tappats bort i Scrumindustrin, sager Dan North, konsult paThoughtworks och en av talarna 
pa 0redev. “ 

“ Scrum ar ingen silverkula som loser alia problem. Foretag fbrsoker fa fordelarna utan att veta hur de ska 
gora och vissa konsulter havdar att de ar experter utan att ha kompetens, sager han. “ Petri Haapio , 
ansvarig att fora in Scrum pa Nokia 


(2011-01-11) Dan Norths blog: 

https://dannorth.net/2011/01/ll/programming-is-not-a-craft/ 


(2011-01-11) Martin fowler comments on Dan North 
https://martinfowler.com/bliki/CraftmanshipAndTheCrevasse.html 


